Sciences et Technologies de l'Information
Sommaire : Trois questions à Hubert Tardieu | L'actualité de la semaine | Théories et concepts | Manifestations | Le livre de la semaine |
ABONNEMENT/DESABONNEMENT| PAGE D'ACCUEIL DE L'ASTI | NUMEROS PRECEDENTS.
Asti-Hebdo
: Quels sont les thèmes de recherche où Sema s'investit.
Hubert Tardieu : Bien que nous opérions sur plusieurs grands secteurs (Télécommunications, Bourse, énergie, grands événements comme les Jeux Olympiques), je vous répondrai à partir d'une de nos activités majeures, les systèmes de paiement. Ils intéressent d'ailleurs tout particulièrement notre groupe. Et ils sont entrés dans une phase de développement explosif, qui appelle de considérables efforts de recherche.
Cela peut surprendre, car, depuis de longues années, on ne faisait plus de recherche en la matière. La première génération employait la carte magnétique pour les terminaux bancaires (DAB/GAB) et de paiement (TPE). La seconde a mis en oeuvre la carte à puce pour des applications de même genre. Les problèmes fondamentaux semblaient résolus. Or la génération qui se développe maintenant, avec le paiement sécurisé sur Internet, pose des défis d'une toute autre ampleur.
L'enjeu majeur porte sur la diffusion des micro-ordinateurs et surtout
des terminaux portables. Il faut en effet, dans le même temps :
- gérer d'énormes volumes de transactions,
- avec les protocoles IP, qui sont peu fiables,
- avec des dispositifs sans fil, donc une communication qui peut être interrompue
à chaque instant,
- dans des conditions sévères de sécurité (authentification, non répudiation) et
de confidentialité.
Nous ne sommes pas directement partie prenante des systèmes enfouis dans les terminaux, mais nous sommes impliqués dans les systèmes centraux et la mise au point des protocoles.
Par exemple, pour les services prépayés, nous étudions tout spécialement la prise d'information dans les environnements mobiles. Les protocoles sont en cours de définition pour remplacer les tickets de communication traditionnels (CDR, Call Detail Recording) par des tickets adaptés aux transactions complexes, les IPDR (Internet Protocol Detail Record). Ils comportent tous les éléments nécessaires à la facturation d'un client, et non pas seulement pour la transaction téléphonique elle-même. Ces protocoles permettent, par exemple, de préciser au protocole IP des priorités et un niveau donné de qualité de service.
Ces points sont relativement simples et restent dans logique traditionnelle de prise d'information à la source. Mais on va plus loin! Par exemple, on envisage de confier au niveau local (le téléphone portatif lui-même) la responsabilité de couper la conversation quand le crédit en prépayé est épuisé. Actuellement, cette gestion se fait au niveau de noeuds de réseau intelligents, ce qui oblige à gérer finement toutes les conversations. Comme le nombre de clients en mode prépayé va augmenter considérablement (beaucoup plus que le post-payé traditionnel), la gestion centralisée de ces millions de clients devient impraticable. Et les protocoles nécessaires à une telle gestion sont très difficiles à concevoir et à développer, d'autant plus que ce domaine est particulièrement exposé à la fraude.
Il faut aussi que le terminal prenne en charge la gestion d'une interface homme-machine de plus en plus sophistiquée, pour la rendre plus ergonomique aussi bien que pour limiter la croissance des effectifs dans les systèmes centraux. Actuellement, par exemple, pour 5000 ou 10 000 abonnés nouveaux, un opérateur de télécommunications doit embaucher un nouveau conseiller clientèle. Ils se comptent par milliers à France Télécom par exemple. Cela ne pourra pas augmenter indéfiniment. On demande aussi au terminal une grande flexibilité de fonctions : tantôt téléphone vocal, tantôt terminal MP3 audio...
Toutes ces fonctions appellent de la puissance de traitement et de stockage. Comme il faut tout de même limiter la consommation, puisque les appareils fonctionnent sur batterie, on demande aux laboratoires de fournir de nouveaux types de circuits, plus flexibles que les Asic (Application Specific Integrated Circuit). Cette flexibilité sert aussi bien à diversifier les fonctions qu'à limiter la puissance consommée. Mais il ne suffit pas de développer de nouvelles technologies matérielles, il faut aussi programmer ces circuits.
Tout cela, combiné, pose des problèmes qui, en logiciel, n'ont pas de précédent. La rupture est aussi forte, et même plus, que le passage, dans les années 80, du batch au transactionnel classique (c'est à dire attaché à un fil). Et il y a du pain sur la planche pour les chercheurs.
Nous avons cru à tort, ces dernières années, que ce genre de problèmes, notamment liés à l'UMTS avaient été résolus par les grands fabricants de portables (Mororola, Nokia, Ericsson), qu'il n'y a avait donc plus rien à rechercher. Or les retards que les grandes marques annoncent périodiquement sur la mise à disposition des terminaux UMTS, et même le rappel par centaines de milliers de certains produits en raison de fautes logicielles, donnent à penser qu'il reste une fenêtre pour des développements complètement nouveaux. Dans les deux ans qui viennent en tous cas.
Hebdo : Mais il s'agit de problèmes de bas niveau ! Vous qui avez été un des créateurs de Merise, un chantre de l'informatique stratégique, n'avez-vous pas l'impression de revenir en arrière ?
H.T. : Concevoir des algorithmes qui ne consomment pas trop d'énergie, cela peut sembler, en effet, être d'un autre âge. En réalité, chaque époque a des contraintes de ce type. L'informatique a toujours été conçue autour d'architectures qui visaient à masquer des déficiences ou des contraintes objectives. Les bases de données palliaient la longueur des temps d'accès aux disques durs. Les protocoles de télécommunications compensaient le manque de bande passante.
Ces contraintes ont disparu, mais le sans-fil en amène d'autres, qui sont celles d'un système d'information en temps réel. Oui, cela nous ramène aux bases de l'informatique. Cela me rappelle les années 80, où les systèmes d'exploitation étaient pourtant déjà largement commercialisés. Pourtant, sur des contrats que nous avons eu à traiter pour la Royal Navy, la bonne solution a consisté à travailler directement avec une machine Ada nue. Le constructeur ne fournissait que la carte processeur et un compilateur Ada. Il fallait donc écrire un noyau exécutif. Mais, du fait des exigences du temps réel, nous nous en sommes bien portés.
Aujourd'hui encore, il existe bien des Unix temps réel, mais il serait impensable de s'en servir pour faire tourner le combiné portable (handset), du fait de leur consommation en énergie. Quant à Windows CE, il ne sait traiter les interruptions temps réel qu'avec de grandes réserves de puissance.
Or, faire par exemple de la gestion de configuration, en sachant que le canal par lequel on envoie la nouvelle version du logiciel peut s'interrompre à tout moment, n'a rien à voir avec la gestion de terminaux en transactionnel classique. Il a fallu du temps pour imaginer les systèmes d'exploitation et les interfaces homme-machine qui convenaient aux micro-ordinateurs. Il en faudra aussi pour en élaborer de bien adaptés aux terminaux portables.
Cela n'exclut pas d'ailleurs des recherches que l'on aurait hier rattachées à l'intelligence artificielle, par exemple le traitement de la voix, qui devrait, je pense, jouer un rôle majeur, en raison de la petitesse des terminaux mobiles qui rendent malaisé l'emploi du clavier.
Quant à la systémique, à l'époque de Merise, le travail consistait principalement à gérer la complexité en central. Aujourd'hui, les questions diffèrent, mais on peut encore se référer à Herbert Simon : la complexité est tissée de simplicité. Il suffit de prendre deux ou trois processus, simples dans leur principe mais bien orthogonaux, pour déboucher sur un processus très complexe. C'est le genre de défi que nous lancent les systèmes à terminaux mobiles.
Et pour la stratégie, je viens de co-éditer un numéro spécial de la revue de l'Idate, Communications & Strategies, sur le thème "From the Net to the New Economy. Critical and Prospective Views". Les considérations sur la segmentation des utilisateurs d'un forum y voisinent des analyses générales. Nous considérons, en particulier, que le logiciel "gratuit" (open source software) joue le rôle d'un catalyseur sur les logiciels standard comme les protocoles (il y aucune raison de payer les gens qui développent des protocoles GSM, des compilateurs XML ou des systèmes d'exploitation). En revanche, quand il faut adapter un logiciel à un métier donné, il y a un travail considérable à faire pour comprendre ce que veut le client, et ce travail doit bien être rémunéré.
Hebdo : Par quel moyen déployez-vous votre stratégie de recherche et développement ?
H.T. : Une chose est sûre : Sema ne participe plus aux grands projets coopératifs de type Esprit ou Eureka. Malgré les ouvertures que nous donnerait notre statut de grande société, le financement apporté se paie d'un coût et de contraintes trop élevés. Nous coopérons donc avec les chercheurs de plusieurs manières différentes.
D'abord nous avons d'importantes équipes internes de recherche et développement. Par exemple, à Naples, pour les portables Internet mobiles. Ensuite, nous coopérons avec des start-up, directement ou par l'intermédiaire de fonds de capital-risque (notamment en Israël et en Californie). Enfin, nous injectons des idées innovantes dans des projets de développement qui intéressent l'un ou l'autre de nos clients. Dans ce cas, en quelque sorte, nous prenons la responsabilité d'un impresario des nouvelles technologies.
Quant aux laboratoires publics, nous entretenons le dialogue avec nombre d'entre eux, français en particulier. Il peut être fructueux, à condition de se garder de relations incestueuses. Ce n'est pas aux chercheurs de nous expliquer comment nous devons faire notre métier, et réciproquement.
Grâce à ces différentes formes de collaboration, nous pouvons déceler les lignes de force de ce qui émerge, et anticiper sur les évolutions à venir sur un an ou deux. Nous ne sous-estimons pas les difficultés inévitables pour toute société de technologie ayant atteint une certaine dimension, comme l'a par exemple bien montré Clayton Christensen dans son livre "The innovator's dilemma" (Harvard Business Press, 1997).
Hebdo : Comment trouver les hommes pour soutenir ce type de recherche et de développement ?
H.T. : La méthode classique consiste à engager des ingénieurs un peu "large bande" et à les spécialiser en leur enseignant les principes les plus adaptés à une technologie donnée et la manière de vaincre les difficultés technico-physiques correspondantes. On parvient à disposer d'excellents spécialistes, capables de ne pas se perdre dans les détails techniques et de se concentrer sur les aspects fonctionnels. Malheureusement, une fois ainsi fortement optimisés sur une génération de problèmes, ils sont tout à fait incapables de comprendre ceux de la génération suivante.
On a vu cela par exemple au moment de l'arrivée des langages de quatrième génération. Formés à la programmation, mais sans avoir suffisamment la "fibre de ingénieur" beaucoup se sont imaginé, à tort, qu'il suffisait de décrire les fonctions de l'application et que l'intendance suivrait, avec ses bases de données et ses interfaces.
Nous allons donc avoir besoin d'ingénieurs et de chercheurs qui n'existent pas encore
aujourd'hui, des gens
- qui comprennent bien ce qu'est la mobilité, Internet, les
langages qui l'accompagnent et des choses aussi "élémentaires" que les
exigences d'un système d'exploitation temps réel,
- qui renoncent aux certitudes acquises avec la génération
technologique précédente,
- qui s'obligent à traiter vraiment un problème concret, et que fassent
preuve d'imagination pour le résoudre.
Comme je vous l'ai montré, la résolution des nouveaux problèmes passe par un retour aux fondamentaux de l'informatique, tout particulièrement les langages, les systèmes d'exploitation et les interfaces. Les compétences stratégiques auront aussi leur importance, car les nouveaux systèmes font intervenir au moins trois opérateurs (le client, le commerçant, le banquier) et souvent quatre (avec l'opérateur de télécommunications).
Les bonnes solutions n'apparaîtront pas tout de suite. Quand nous nous sommes attaqués à ce qui allait devenir Merise, nous étions face à un foisonnement de nouvelles technologies et de nouveaux problèmes. On ne savait pas "par quel bout attraper le saucisson". Il aura fallu trois ou quatre ans pour élaborer une méthode qui permette de se passer de gourous. Il en ira de même avec la téléphonie mobile.
Le numéro 9/2000 de TSI donne sur la question des approches plus théoriques, sous l'angle du logiciel et des approches objet en particulier.
On est à la rencontre de deux mondes qui s'avancent l'un vers l'autre : XML est la pointe avancée des "mark-up languages", c'est à dire du balisage des textes pour en permettre une utilisation automatisée (au départ, pour l'impression, aujourd'hui, pour toutes sortes d'utilisations, en particulier l'EDI). Java est le plus récent des langages orientés objet, et en visant le web, a été conçu pour s'intégrer à ses outils et à prendre place au sein des pages HTML, discrètement mais efficacement. XML, c'est la dorsale éruptive entre deux grandes plaques tectoniques du monde du texte... et nous n'en avons sûrement pas encore vu les dernières éruptions.
Mais les auteurs n'ont, dans cet ouvrage au moins, que faire de considérations philosophiques, et entendent surtout guider leur lecteur dans des réalisations pratiques. Les animateurs de recherche qui listent d'Asti-Hebdo apprécieront en particulier qu'un des trois exemples traités soit précisément "un portail d'information avec chaîne de publication", clairement inspirée des processus d'une revue scientifique avec ses phases de révision puis de publication finale.
On notera au passage que le CD-Rom porteur du code des exemples, assez classique maintenant dans la littérature destinée aux développeurs, cède la place à une simple URL : cliquez, vous aurez tout ce qu'il vous faut. A quand la phase suivante, où le livre-papier disparaîra au profit de l' "ebook", et où le programmeur aura un oeil sur l'écran de sa station et l'autre sur celle du son livre électonique... tous deux connectés au serveur de l'éditeur (Eyrolles Cosmobay, en l'occurence) aussi bien qu'à l'atelier logiciel de son employeur ou de son client? P.B.